1. Field of the Invention
The present invention relates generally to device test and simulation, and more particularly, to systems and methods for preparing for a device test and simulation.
2. Description of the Related Art
Development of a new device such as an integrated circuit, or other electronic device, requires extensive testing to determine if a proposed design meets the design performance requirements. One approach to developing a new device includes simulating the device such as by designing a computer program that simulates the operation of the device being developed (i.e., development device). Such a computer program is typically referred to as a device simulation. Device simulations are typically run in a test bench environment. As the new device development progresses through the various developmental phases (i.e., a developmental cycle) an actual hardware prototype device is typically built and tested. The test bench environment can also be used to test the prototype device.
Development devices are typically defined in a design document referred to as a product specification. By way of example, a product specification for an ASIC development device would define the required operations, I/O requirements and performance (e.g., speed, power and thermal efficiency). The ASIC device product specification can also include physical aspects of the development device (e.g., device size, circuit design, materials, manufacturing processes, etc.). As the development device is refined during the development cycle, the product specification is correspondingly refined.
As discussed above, new devices under development are tested throughout the development cycle. By way of example, a test of the simulated development device can identify performance problems that in turn require design changes and corresponding product specification revisions. Later, during the prototyping phase, tests of the prototype development device can result in design changes and corresponding revisions to the product specification.
Typical test bench set up requires a very laborious, manual, detailed review of the product specification to define and set up all of the test parameters of the then current revision of the development device. By way of example, registers are widely used in ASICs. Each register is defined by a location, a size (i.e., number of bits) and a type (e.g., read only, write or read/write). Other aspects of each register can also be defined. It is very common that registers used in the development device will change though the development cycle. By way of example, a register may change in size or location.
FIG. 1A is a flowchart of the method operations 100 of a typical register set-up for a development device test. In operation 105, a product specification is received. In operation 110, the product specification is manually reviewed to determine the various parameters of each register. In operation 115, each register is manually set up (i.e., the various parameters of each register are manually entered into the test bench or simulation). In operation 120, the registers in the development device are tested. Often an additional operation is also added that includes running a verification check on the testing data entered in the test bench. This verification check typically examines the testing data to make sure all the data required to perform a test is entered (e.g., all the data fields have “something” in them). However, the verification operation does not and cannot compare the testing data that was actually entered in the test bench to the data in the product specification.
One of the problems with the above manual data entry method, operations 100, is that there are many opportunities for missing data or erroneous data entry that can then cause the development device to fail the test. Alternatively, the missing data or erroneous data entry can cause one or more aspects of the development device to not be tested at all. In either case, the manual data entry approach is very likely to introduce failures rather than detect actual problems. In addition, the manual data entry approach can be extremely labor intensive and time consuming, thereby unnecessarily extending the development cycle.
FIG. 1B is a flowchart of the method operations 150 of a typical register set-up for a development device test for a revised product specification. In operation 155, the revised product specification is received. In operation 160, the revised product specification is manually reviewed to determine the changes to any of the various parameters of each register. In operation 165, each register set up is then manually updated (i.e., the various revised parameters of each register are manually entered into the test bench). In operation 170, the registers in the development device are tested.
As described above, additional errors can be introduced with each revision to the product specification. In view of the foregoing, there is a need for a simpler and more precise method of extracting the development device parameters from the product specification and applying extracted parameters to the test environment.